During execution of computer programs, computers use resources, such as memory, modems, printers, databases, etc. Many of these resources are only used periodically by any given computer program. To take full advantage of resources, computer networks have been developed in which processes running on many computer devices or “nodes” can share resources. Consequently, instead of having to purchase one printer for every computer, users may purchase a single printer for use by many computers that are connected to a network. Processes on each computer on the network access the printer only when the processes seek to use the printer.
Even though resources may be shared, many resources may not be used by more than one process at a given time. For example, most printers are unable to print more than one document at a time. Other resources, such as data blocks of a storage medium or tables stored on a storage medium, may be concurrently accessed in some ways (e.g. read) by multiple processes, but accessed in other ways (e.g. written to) by only one process at a time. As a result, mechanisms have been developed to control access to resources.
One such mechanism uses locks. A lock is a data structure that indicates that a particular process has been granted certain rights with respect to a resource. There are many types of locks, some of which may be shared by many processes, while other types prevent any other locks to be granted on the same resource. FIG. 1A illustrates a hierarchy of lock modes that may be used to govern access to a table in a database.
At the lowest level in the hierarchy is a NULL mode lock 160. Ownership of a NULL mode lock on a table grants a process no permission to access the table in any manner. Ownership of a concurrent read lock 158 grants a process permission to read the table, but does not guarantee that other processes are not concurrently writing to the table. Ownership of a protected read lock 154 grants a process permission to read the table and guarantees that no other process is concurrently writing to the table. Ownership of a concurrent write lock 156 grants a process permission to write to the table, but does not guarantee that another process is not also writing to the table. Ownership of a protected write lock 152 grants a process permission to write to the table and guarantees that another process is not also writing to the table. Ownership of an exclusive mode lock 150 grants a process permission to perform any operation on a table, and guarantees that no other process is performing any operation on the table.
Due to the various permissions and guarantees associated with these locks, certain lock combinations are not allowed. For example, if a process owns an exclusive mode lock on a resource, then no other process can be granted any lock other than a NULL mode lock. If a process owns a protected write lock, then no other process may be granted an exclusive mode lock, a protected write lock, a protected read lock or a concurrent write lock. If a process owns a protected read lock, then no other process may be granted an exclusive mode lock, a protected write lock or a concurrent write lock. If a process owns a concurrent write lock, then no other process may be granted an exclusive mode lock, a protected write lock, or a protected read lock. If a process owns a concurrent read lock, then no other process may be granted an exclusive mode lock, etc.
A lock that may be held by more than one process at a time is referred to as a shared lock. For example, concurrent read locks are shared locks because two processes can hold concurrent read locks on the same resource at the same time. In one arrangement, before a process can perform an operation on a resource, the process is required to obtain a lock that grants to the process the right to perform the desired operation on the resource. To obtain a lock, a process transmits a request for the lock to a lock manager, which is a process responsible for managing locks to resources, such as, granting, queuing, and keeping track of locks, etc. A lock manager usually manages locks for a group of processes. In one arrangement, a process is a program executing a particular task.
In a multi-node network system, various processes being run in a group of nodes (a “node group”) may be assigned to a lock manager that resides in one node (the “master node”) of the node group. If any process in a node of a node group seeks to access a resource, the process sends a lock request to the lock manager on the master node of assigned to the node group. Because the lock manager manages locks for all nodes in the node group, the lock manager may reside in a node that is remote from the node executing the process that is requesting the lock (the “requesting node”).
In one approach, if a requesting node is remote from the master node, then the requesting node is required to send a message to the remote master node. The lock manager then sends a response message to the requesting node to notify that node about whether a lock may be granted. Two messages are required to complete a lock request transaction in this approach: one from the requesting node to the master node and one from the master node to the requesting node. Further, even if the lock manager can grant the lock to the requesting node without any conflict, the requesting node has to wait for the response message from the lock manager before being able to obtain the requested lock.
When none of the nodes in the node group is holding an exclusive lock, and the requesting node is seeking a shared lock, the lock manager can grant the lock to the requesting node because there are no conflicts. However, the requesting node must still wait for the response from the master node before accessing the resource that corresponds to the lock. Waiting for the response from the lock manager under these conditions increases latencies and causes a delay in request processing.
Based on the foregoing discussion, it is clearly desirable to provide techniques for improving the efficiency of lock management, particularly in situations where a node in a node group seeks to obtain a shared lock.